home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Commodore Free 12
/
Commodore_Free_Issue_12_2007_Commodore_Computer_Club.d64
/
t.soasc how
< prev
Wrap
Text File
|
2023-02-26
|
14KB
|
554 lines
u
SOASC= Project - HOW WAS IT DONE
The SOASC= project is an automated
recording technique invented by me
(Stone Oakvalley) in order to mass
record music from the legendary CBM 64
and its SID chips (6581 & 8580).
Realizing this project needed unique
hardware solutions & software to back
it all up. I spent approx 180 hours on
research & how to figure a plan that
would help automatically record this
massive amount of CBM 64 music. Here is
a more or less complete detailed
description of all the problems and
solutions I encountered.
INTRODUCTION
First download the whole HVSC SID
Collection & unpack
PREPARING MADNESS
I then programmed a tool in PureBasic
to interpret and extract out the Path+
Filename i.e. "/20CC/Conquestador.sid"
and then all the subtunes length from
the songslength string: "3:28 3:42 4:39
0:01(G) 0:01(G) 0:09(G)" from the file
in the HVSC collection
"C64Music/DOCUMENTS/Songlengths.txt"
I then made my own database .txt with
and looped output like: 20CC/
Conquestador.sid
3:28
3:42
4:39
0:01
0:01
0:09
#(Separator)
etc....into a large file containing all
song info from the "Songlengths.txt"
MAPPING THE SID'S
Then I binary read each .SID file and
checked the amount of sub tunes within
it. I hacked the SUB-TUNE bit in the
SID file to make the SID file start on
this tune when played, and then I made
a duplicate file of it. (This is
because the PSID64 SID Player could
not be used to skip tunes, and my
system did not have any support to
send any additional keys either to the
C64. More on this later) Then I
extracted the required info I needed
for the SIDREC recorder and when
constructing the MP3 tags. I created a
unique .INI file for each SID sub-tune
file like this, based on the info from
the SID file:
Filename: "0000101.INI" etc etc (More
about this filename later)
[SID-DATA]
PATH = 20CC/
FILE = Conquestador.sid
TUNE = 01%3:28 (This means Tune 01 is
3:28 long);
[MP3-DATA]
MP3-FILE = Conquestador_T01.sid.mp3
(The new filename to indicate Track 01)
MP3-TITL = Conquestador
MP3-AUTH = Edwin van Santen & FalcoPaul
MP3-YEAR = 1991
MP3-COPY = German Design Group
With the above procedure the amount
of files of course increased to 46668
.SID files and 46668 .INI files
FILENAMES
Then all the files was renamed (both
.SID and .INI) into my own charset
for usage towards the PAR: Relay C64
keyboard interface. The num of chars
used in the filename created in step 3
above needed to be a little bit
compressed, due to the fact that there
were 50000 unique filenames and I also
needed bits in the PAR: ports to send
SHIFT and other special C64 keys,
including reset and SCROLLLOCK
detection for the 64HDD server. Anyway
a filename like "3207101.INI" was
renamed to "32O7LOL.INI" Where "1"
was replaced by "L" and "0" (zero) was
replaced by the letter "O" This
renaming caused the recording process
to begin not at the top of the
alphabet but really in the
"VARIOUS/N-R/" directory, which
contains approx 23000 tunes. And most
of the "VARIOUS" tunes is not really
what we all remembered from the good '
ol C64 gaming days! Gimme Rob Hubbard!
BILL GATES AND HIS "oughta's" After
the renaming of approx 95000 files was
done, I had to convert each .SID file
into CBM 64's .PRG format by
using the excellent PSID64.exe dos
software which makes an C64 executable
out of a .SID file which can be
executed on the real C64 containing
player code + textual information from
the HVSC tags.
A couple of files were detected as not
playing, or had problems being
converted during this conversion
process. These files will be recorded
after the main project is finished
using alternative recording methods.
Anyway, the amount of files in this
project went to a whopping 142134!
(.SID, .INI and now .PRG files)
Yeah, working with these amount of
files was beginning to slow down
Windows XP even. They were later
sorted out into 9 different
directories just because DOS and WINME
on the ServerPC and RecordingPC could
not handle this amount of files in one
dir. Stupid Bill Gates and his "oughta
be enough for everybody" shit!!! Now,
I had to start on the hardware part
which was a really painstaking job..
CABLES AND COMMUNICATION
Now all the .PRG files was copied
over to the ServerPC HD, and by
running the 64HDD software which
emulates a 1541 Disk Drive for C64 in
DOS, the C64 could now access the
files and load+run+play them. A own
cable was made (XE1541 see pictures)
to support the 64HDD and was connected
to the Serial Port of the C64 and the
PAR: port on the PC. Getting 64HHD up
and running was not the most easiest
part (also due to PAR: bios setups),
and the diodes used in the XE1541
cable was hard to come by. I had to
make 2 of everything, and that added
some delays to the project.After 1
week of constant testing and
configurating it finally worked like a
charm! Also, a Audio/Video 5-pin cable
had to be made and was connected to
the AUDIO/VIDEO connector at the C64.
KEYBOARD INTERFACE - MAGIC FINGERS
TYPIN' ON THE C64'S! To be able to
load automatically on the C64 by real
typing chars, an easy and crude
solution had to be constructed. The
result was the homebuilt Parallel
Relay Card connected to the C64
keyboard connector using a IDE 44pin
cable (which fits 100% by the way) The
interface consists of 8 relays which
are each connected to the PAR: port.
By programming again in PureBasic I
could switch these relays on and off
by command, and thus simulating keys
to be pressed on the real C64, letting
me load all the different filenames
including the keys to LOAD & RUN the
.PRG file as well on the C64. Since I
had limited with PAR: bits to play
with, it was a little bit tricky to
optimize what chars I needed to get
everything run & record automatically
in an long lasting loop for about 13
weeks! The PAR: Relay C64 Keyboard
Interface was designed as follows,
entry after "=" is the actual
C64 key:
PAR 01-BIT01 = 2
PAR 01-BIT02 = 3
PAR 01-BIT03 = 4
PAR 01-BIT04 = 5
PAR 01-BIT05 = 6
PAR 01-BIT06 = 7
PAR 01-BIT07 = 8
PAR 01-BIT08 = 9
PAR 02-BIT01 = L - for loading
PAR 02-BIT02 = O - for loading
PAR 02-BIT03 = , - for specify the
C64 DEVICE num
PAR 02-BIT04 = : - : because ":" +
SHIFT + RUNSTOP = LOAD & RUN in one go
at theC64
PAR 02-BIT05 = SHIFT
PAR 02-BIT06 = RUN STOP
PAR 02-BIT07 = HARD RESET C64 -
Userport pin 1 & 3...cold reset
PAR 02-BIT08 = SCROLL LOCK - Off when
not loading tune, ON when loading on
64HHD Server
So, by resetting C64, loading, waiting
and run a SID tune .PRG file, the
PureBasic code was like this:
Procedure C64_Load(); Will write out
L+SHIFT+O+
"
CallFunctionFast(*out,$378,254) ; KEY
LDelay(del)
CallFunctionFast(*out,$378,255) ; OFF
Delay(del)
CallFunctionFast(*out,$378,237) ; KEY
SHIFT + O
Delay(del)
CallFunctionFast(*out,$378,255) ; OFF
Delay(del)
CallFunctionFast(*out,$378,239) ; KEY
SHIFT ON
Delay(del)
CallFunctionFast(*out,$278,254) ; KEY 2
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
CallFunctionFast(*out,$378,255) ; OFF
Delay(del)
;Will write out the .prg name
;7 letters to check
For a=1 To 7
If Mid(REC$(counter),a,1)="O"
CallFunctionFast(*out,$378,253) ; KEY
O
Delay(del)
CallFunctionFast(*out,$378,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="L"
CallFunctionFast(*out,$378,254) ; KEY
L
Delay(del)
CallFunctionFast(*out,$378,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="2"
CallFunctionFast(*out,$278,254) ; KEY
2
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="3"
CallFunctionFast(*out,$278,253) ; KEY
3
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="4"
CallFunctionFast(*out,$278,251) ; KEY
4
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="5"
CallFunctionFast(*out,$278,247) ; KEY
5
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="6"
CallFunctionFast(*out,$278,239) ; KEY
6
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="7"
CallFunctionFast(*out,$278,223) ; KEY
7
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="8"
CallFunctionFast(*out,$278,191) ; KEY 8
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="9"
CallFunctionFast(*out,$278,127) ; KEY 9
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
Next
a
;Will write out the extension part
",9:+SHIFT+RUNSTOP = Auto Load and RUN!
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
CallFunctionFast(*out,$378,239) ; KEY
SHIFT ON
Delay(del)
CallFunctionFast(*out,$278,254) ; KEY 2
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
CallFunctionFast(*out,$378,251) ; KEY ,
Delay(del)
CallFunctionFast(*out,$378,255) ; OFF
Delay(del)
CallFunctionFast(*out,$278,127) ; KEY
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
CallFunctionFast(*out,$378,247) ; KEY :
Delay(del)
CallFunctionFast(*out,$378,255) ; OFF
Delay(del)
CallFunctionFast(*out,$378,207) ; KEY
RUN STOP + SHIFT = LOADING AND RUN!
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
CallFunctionFast(*out,$378,255) ; OFF
; Here we wait for a signal from C64
server thorugh the SCROLL LOCK which
will light when loading is on, and off
when done!
MeasureHiResIntervalStart() ; Start a
timer to detect endless loop in case
the SCROLLLOCK or 64HDD server crashes!
Repeat
Delay(1)
SetGadgetState(#Load,1)
If MeasureHiResIntervalStop()>120
;
Seconds. If timer reached this limit,
then 64HDD server is down or the
scrolllock is not working!
MessageRequester("INFO","Timeout: No
response from 64HDD / SCROLL LOCK
Check
connection! - Please restart"
)
CloseLibrary(0)
End
EndIf
Until CallFunctionFast(*inp,$279)=126
Or CallFunctionFast(*inp,$279)=255
;
ScrollLock (64 server loading)
detection on
MeasureHiResIntervalStop()
Delay(1000)
MeasureHiResIntervalStart() ; Start a
timer to detect endless loop in case
the SCROLLLOCK or 64HDD server crashes!
;Another loop because 64HDD sends a
double scroll lock ON/OFF signal
quite fast.
Repeat
Delay(1)
SetGadgetState(#Load,1)
If MeasureHiResIntervalStop()>120 ;
Seconds. If timer reached this limit,
then 64HDD server is down or the
scrolllock is not working!
MessageRequester("INFO","Timeout: No
response from 64HDD / SCROLL LOCK
Check connection! - Please restart"
)
End
EndIf
Until CallFunctionFast(*inp,$279)=126
Or CallFunctionFast(*inp,$279)=255
;
ScrollLock (64 server loading)
detection on
MeasureHiResIntervalStop(
)
SetGadgetState(#Load,0)
EndProcedure
Of course there is more code needed,
but thats not important, it was just
to mess up your reading! Hehe
THE FIRST SETUP
During the first 180 hours of research
of the project, The first setup with
just 1 pcs 8580 CBM 64. This setup was
used for several weeks while designing
the software and constructing the
hardware. It was really placed in a bad
position & was really annoying to have
around... well that's life.
HARDWARE SETUP
MADNESS MANIFESTSITSELF
1 x CBM 64 BreadBox with 6581
SID Chip.
1 x CBM 64 WhiteyBox with 8580
SID Chip.
2 x Server PC's (33MHz and 233MHz)
running in DOS mode with 64HDD as
fileserver for the CBM 64 .prg's
2 x Recording PC's (800Mhz and
933Mhz) running in WinME with own
programmed record software (SIDREC).
2 x 1084 Monitors.
4 x 15 Inch Monitors
2 x Own constructed PAR Relay to
CBM 64 keyboard interface.
2 x Homemade XE1541 Cables.
2 x Homemade Audio/Video CBM 64 Cables.
12 x 220V Power plug connections needed
As you can see from the pictures, the
hardware setup is a real mess. But if
it works, who cares :)The keyboard and
top chassis of the CBM's are removed.
A own tool called SIDREC (for Windows)
was programmed in PureBasic which
controls everything & keep track of the
recording process. The function of the
program is to RESET, LOAD, RECORD,
CONVERT, MAKE MP3 (with tags from HVSC
.INI files) and go in a loop for about
13+ weeks, 24 hour a day! It also
detects when 64HDD has finished loading
the .PRG file into the C64, at which
point the SIDREC start to record the
tune. A ServerPC & a RecordPC was setup
(with no cabinets for easier access) &
put on a huge table with 6 CRT's and a
s**tload of power connectors & my God
the wires!
Pictures here will tell their own
story, you can see all the software
running & the 8580 C64 in action. A fan
system (running at 5v) was also made to
cool down the SID chip, 2 HD's C64
power supply & a old crappy 33MHZ SX
Processor!
GETTING THE BOXES
Getting hold of CBM 64's wasnt as easy
you would have thought. I searched some
Norwegian net auction pages, & ended up
with a couple of defect C64 breadboxes.
My own two C64's had a busted 8580 SID
chip and something wrong with the video
or char chip. Anyway, during 2 months
time in search for cheap C64' I ended
up having 5 pcs 6581 C64's and 4 8580
C64's.. Well, they will make a great
addition to my nostalgic showcase
cabinet along with the Amiga 500/Atari
2600 from the 80's together with some
old magazines, game box casing & data-
settes, disk drives & joysticks..hehe!
FINAL WORDS
Well, here I am - Stone Oakvalley with
the most comprehensive and insane
project to this date. Looking on the
project I must say the work involved
kinda payed off. For who else can
claim the throne of producing the most
complete, real and authentic CBM
64 SID music database in the world?
From the 19th of November 2006 the
SOASC= project will record
automatically & process about 1000
tunes each 24 hour session for both
the 6581 and 8580 SID models. Expected
date of finalizing should be somewhere
in March 2007!
FACTS OF PROJECT:
Based upon HVSC #46 SID database, for
both 6581+8580
66000 SID Files
97508 Files
178676 Minutes of music
2978 Hours of music
124 Days (24h) of music
One persistant human
End result? - Well: 97508 MP3 files
with a total size of approx 300GB of
CBM 64 SID music.
See you around!
Regards Stone Oakvalley,
Interview by Stein Eikesdal